Policy Based SIP Signaling Management in IMS

Manageability, the theme for IMS to compete with existing heterogeneous Voice over IP (VoIP) applications, runs over every network element in NGN for security and quality of experience (QoE). Further decomposition of IMS Core Network (CN) has resulted in a rapid increase of signaling traffic. At the same time, the ever rising of applications over signaling, the needs of message validation and screening, and request prioritizations are all making SIP signaling management a required capability for IMS commercialization. This paper analyzes the current problems in IMS signaling handling by setting up different application scenarios. In light of efficient and consistent services delivery, a policy based SIP signaling management mechanism is proposed, in order to meet the versatile requirements from both operation and applications perspectives. Example scenarios and deployment suggestions are also provided. 1. Challenges to IMS Signaling Stratum Ever since the Signaling System 7 (SS7) introduced the out-of-band signaling, people have tended to think differently of the signaling and bearer network. Although the use of User-to-User Information (UUI), like Short Message Service (SMS), has demonstrated a kind of reviving of the in-bind signaling in mobile network, the limitation of message size mitigates its impact to the overall divine signaling network. When IMS takes the dominant role as the Next Generation Net-work (NGN) core for both wireless and wireline, however, a careful study of IMS signaling stratum is necessary. The increase of signaling traffic in IMS originates from various IMS applications as well as IMS complex interfaces. A vivid characteristic of IMS is its flexibility in orchestrating various applications, be it traditional telecom based like customized applications for mobile network enhanced logic (CAMEL) or internetoriginated like Google Map. Such flexibility has inevitably introduced more signaling information exchange and processing, especially when most application information is exchanged in EXtended Markup Language (XML) format. XML, though rich in its applications, clear as it is self-explanatory, is infamous of its size [1]. Compared with legacy ISUP messages, the SIP methods/headers will support more applications either coupled or de-coupled with the signaling path. The priority for each method/header is dynamic and flexible as they are associated with specific applications. How to assure the timely processing of the most needed request, especially during system congestion, is a key issue to be resolved for IMS deployment. 1.1 More Applications over Signaling in IMS With the introduction of SMS, the signaling network is no longer dedicated to signaling itself because the real contents have been directly passed from user to user. In IMS, traffics of the SIP-based Instant Messaging (IM) and Presence applications are combined with the session control messages in the signaling stratum. In order to distinguish them from normal applications, we call them Application over Signaling (AoS), i.e., application contents are bundled with the signaling protocol in the same path. Presence and IM, which are two typical IMS applications, are tightly coupled with the SIP signaling. Presence utilizes SIP NOTIFY method, while IM relies on the SIP INVITE or MESSAGE method to transfer the service information. The contents of these two are transferred via the SIP signaling path, in XML format. Compared with typical session related SIP messages, Presence messages are relatively large (can be up to 1M bytes). The burgeoning of AoS challenges the IMS signaling network engineering. First, unlike the well-known Erlang traffic model, Presence and IM traffics have more unpredictable factors. For Presence, the number of federated presentities [2] per watcher will greatly impact the message size as well as the sending rate. Furthermore, user behavior will varies widely as we could expect a fast moving user to generate more location update information than a busy newspaper editor at the desk [3]. Second, besides the need to safeguard the normal signaling traffic, it is necessary to provide a kind of Quality of Service (QoS) for these AoS, which should be considered as one indispensable part of Service Level Agreement (SLA). 1.2 The Need of Signaling Screening Traditional QoS control in IMS network only handles bearer stratum resources. When everything goes in IP, however, there is a need to scrutinize signaling network too. Compared with bearer network, we always treat signaling network as a safe, reliable, and fast one. This is true in SS7 when user information can hardly be passed to the signaling network. Such restriction gets loosen when SIP rules over both user-to-network interface (UNI) and network-to-network interface (NNI). Since SIP is text-based, it has left enough space for hacks to abuse the signaling network resource for their real contents exchange. Similar to the local policy that Application Function (AF) exerts to authorize the proper bandwidth request [4], SIP signaling should be screened to authorize subscriber’s signaling request based on operator’s regulation. Unlike the SS7 network, IMS has no explicit definition of UNI and inherits the nature of SIP to tolerate extensions. P-CSCF can perform screening on sensitive headers related to UE access, charging; but it won’t prevent IMS client from utilizing other SIP headers, tokens, and parameters for its proprietary solution. SIP protocol is lack of over-length signaling control, while Message Transfer Protocol (MTP) in SS7 has explicit requirement of 272-octet message length limit. Potential unauthorized signaling usage will increase call setup delay, and hence brings in more burdens on IMS signaling processing. 1.3 Overload Control Needs An IMS system is said to be overloaded when it is offered more traffic than its designed capacity. In the NGN control plane, signaling traffic is the major concern of the IMS system congestion. Overload control, as a key performance index, is targeted to maximize the successful call setup rate and reduce the network resource on calls that will ultimately fail. The distributed architecture of IMS is increasing the signaling exchange among IMS network elements, and the various usages of IMS signaling, such as multimedia session, AoS, QoS, etc, are bringing in more uncertainties to the overall system signaling traffic model. Growing signaling complexity triggers more consideration on the efficiency and flexibility of the IMS system overload control. With the evolution of UMTS CN, highly distributed architecture is complicating the signaling exchange in terms of the number of network elements and the interfaces between them, which is shown in Figure 1. Figure 1: Network Elements and Interfaces Increment in